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SYSTEM AND METHOD FOR CHECK 



EXCEPTION ITEM NOTIFICATION 



CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims priority to provisional application number 
60/190,176 filed March 17, 2000 entitled DISBURSEMENT EXCEPTION 
IMAGES, the entirety of which is hereby incorporated by reference. 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention generally relates to a system and method for processing 
checks and, more particularly, to a check exception item notification system and 
method which provides a client with notification of exception items through e-mail. 

Description of the Related Art 

The financial services industry has long provided its customers with the 
ability to write checks and similar negotiable instruments. In current practice, a 
payor (e.g., a client of a bank or financial institution) writes a check representing an 
amount to be deducted from the payor's account. The check is given to a payee. 
Checks are normally presented for payment by the payee to the payee's banking 
institution (the "payee bank"). In turn, the payee bank presents the check to the 
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payor's bank for payment. The payor's bank then pays the payee bank, and deducts 
the amount of the check from the payor's account, against which the check is drawn. 

In order to prevent fraud and/or mistakes, most banks with large institutional 
clients offer these clients a service known as check exception processing. Large 
institutional banking clients issue a significant volume of checks on a daily basis. For 
example, an insurance company might issue several thousand checks in a single day 
in the course of processing insurance claims. The client provides the bank with a file 
listing information of all of the checks that it has issued (an "issue file") to payees. 
In performing the exception processing, the bank compares the checks issued by 
these clients with the checks that are presented for cashing by the payee bank. 

When the payor bank receives a request for payment from the payee bank 
with respect to a check presented by a payee, the payor bank will then compare the 
information on the presented check with the issue file using, for example, the 
magnetic ink character recognition ("MICR") line. When a check is issued by a 
payor, a MICR line is usually added to the check and includes the check number and 
the payor account number. When the payor bank processes this check, the amount of 
the check is also added to the MICR line. If the payee check matches with a check in 
the issue file, (e.g., if the amounts, and check numbers match) the payor bank has 
confidence that the presented check is valid and pays the payee's bank. If the payee's 
check does not match any item in the issue file, the payee check is labeled an 
"exception item". Each business day, the payor bank provides the client of the 
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exception service with a list of the exception items and inquire as to whether the 
client is interested in paying each exception item. 

Prior art methods for actually notifying clients of exception items have not 
satisfied the needs of clients who have large numbers of checks written each day. 
For example, typical prior art notifications include CD-ROMs containing exception 
check images or reports, digital image microfilm, dial-in online access using bank 
proprietary software, facsimile, telephone, paper, tape and transmission index 
reports. Some systems allow the bank's client to connect to the bank system 
electronically through a network such as the Internet and view exception items. 

In most of these network connections, the list of exception items is "dirty" or 
"unscrubbed" in that the items are typically the result of an electronic mismatch and 
not reviewed by bank personnel before the clients are allowed to view the exception 
items. This means that the exception list may include mis-encoded items, duplicate 
items, or items with stop payment instructions already on file. Mis-encoded items 
include checks where an operator keyed in the incorrect dollar amount or check 
serial number in the MICR line even though the dollar and check serial number 
fields on the face of the check are correct. In addition, in most prior art systems, the 
exception client is not shown an image of the exception check. Such an image must 
be requested separately and so the exception client typically does not have enough 
information to determine whether to authorize or decline payment of the check. 
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Therefore, none of these prior art methods and systems can satisfactorily 
handle the massive influx of checks and exception items produced daily by large 
institutions. Nor can these prior art systems handle the need of large institutions to 
have a list of "true" suspect items (i.e. an exception list that is "clean" or "scrubbed" 
to remove mis-encoded items, duplicate paid items, and items with stop payment 
instructions on file). Moreover, prior art systems do not provide corresponding gray- 
scale images of check exception items so that the client has all available information 
to make an accurate determination as to whether to authorize or decline payment of 
an exception item. 

Further, in the systems where a form of media is sent to the client, there is 
necessarily a delay between the production of an exception item, and notification of 
that exception item to a client. A defined period of time must pass before a bank 
ceases gathering exception items to be included in the media (e.g., CDROM, paper, 
etc.) and subsequently sent to the client. Thereafter, the media must be physically 
sent to the client thereby incurring further delays. Finally, there may be a delay in the 
client's response as to whether the exception item should be paid. Such delays are 
undesirable because banks must meet a deadline established by the U.S. Federal 
Reserve Bank ("Fed") to submit all "return" items (those items identified by the 
client as suspect or fraudulent) that should be sent to the payee bank for credit. 
Clearly it is desirable to provide client's of the payor bank with as much time as 
possible to determine why a particular item is an exception item. 
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Therefore, there exists a need in the art for a system and method of providing 
clients with notification of check exception items which is faster, more efficient, and 
easier to use than the techniques of the prior art. 

SUMMARY OF THE INVENTION 

A system mainframe receives and compares issue and presentment files with 
one another to produce a list of exception or "suspect" items. The comparison can 
include, for example, a comparison of account numbers, check numbers, and check 
amounts. A processor then obtains images for checks which are associated with the 
exception items. The exception items are cross-referenced with a database of clients 
of the system to produce an exception file relating to clients of the system. The 
exception file for clients of the system and images of the checks corresponding to the 
exception items in the exception file are fed to a server. The server produces a Web 
file (including the exception item description and the corresponding images) and 
corresponding uniform resources locator ("URL") to address the web file. Each URL 
is unique to both the individual e-mail address and file so that two individuals do not 
access the same web page even if the exception information sent to these two 
individuals is identical (for example, two individuals within the same company 
which receive exception notification for the same account). Moreover, the URL is 
changed each time a new web file is generated. 

The server also produces an e-mail notifying the exception client of the 
exception item. The e-mail includes a hyperlink to the created URL. In operation, 
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the exception client receives the e-mail, links to the Web file through the use of the 
hyperlink, and quickly accesses the Web file. Once connected with the Web file, the 
exception client authenticates with the server and authorizes or declines payment of 
the exception item. Due to deadlines imposed by the FED, if a client does not 
submit a processing instruction (e.g. "pay" or "return") within a negotiated deadline, 
a default instruction will be used. The web files are set to expire at a preset time 
every business day so as to prevent access after the negotiated deadline. 

Thus, a faster, more efficient, and easier to use system and technique is 
available than systems and techniques of the prior art. 

These aspects, as well as others, will become apparent upon reading the 
following disclosure and corresponding drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For the purpose of illustrating the invention, there is shown in the drawings a 
form which is presently preferred, it being understood, however, that the invention is 
not limited to the precise arrangements and instrumentalities shown. 

Fig. 1 is a diagram of a check exception item notification system in 
accordance with the invention. 

Fig. 2 shows an example of an e-mail generated in accordance with the 
invention. 
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Fig. 3 shows the contents of a typical Web file used in accordance with the 
invention. 

Fig. 4 is a diagram of an image file created in accordance with the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring to Fig. 1, there is shown a check exception item notification system 
20 in accordance with the invention. An issue file 24 relating to payor checks and a 
presentment file 22 relating to presented checks submitted by payees requested for 
cashing against accounts of clients of a financial institution using system 20, are both 
sent to a system mainframe 26. 

System mainframe 26 compares presentment file 22 and issue file 24 with 
each other to produce a list of exception items 28. The comparison could include, 
for example, a comparison of account numbers, check amounts, and check numbers 
in issue file 24 with items presented for payment in the presentment file 22. 
Mainframe 26 could also review issue dates of checks in the presentment file to 
determine if checks presents are "stale" (e.g. more than a specified number of days 
past the issue date, such as 180 days past the issue date). Additionally, mainframe 
26 could review the amount of a check presented to see if it is beyond a particular 
dollar value and so would merit review by a client based on parameters set during 
service implementation. 
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When a comparison of issue file 24 and an item presented in the presentment 
file 22 do not match, an exception item is created. Such an exception item could be a 
pointer pointing to the representation of the check in the presentment file 22 that did 
not match the corresponding representation of the check in the issue file 24. 
5 Alternatively, the exception item could be a copy of the item in the presentment file. 
System mainframe 26 produces an exception file 28 of these exception items. 

Exception file 28 is sent to an image archive processor 30 which performs an 
image matching process using data from presentment file 22 to produce images 
corresponding to each exception item thereby producing an image exception file 34. 

10 Each image can then be shown to a client 1 12 of a bank using system 20 to assist the 
client 1 12 in determining whether to authorize or decline payment of the exception 
item. Image archive processor 30 can be, for example, an image distribution and 
support system such as the MIDAS (Multi-processing Image Distribution and 
Support System) owned by LP. MORGAN CHASE & COMPANY. The images can 

15 be in, for example, a JPEG (Joint Pictures Experts Group) format, an ABIC 

(Adaptive Bi-Level Image Compression) format, or a TIFF (Tagged Image File 
Format) file. 

A scrubbing system 36 may be used to review image exception file 34 for 
accuracy and select only "true" exception items to remain in image exception file 34. 
20 For example, an operator of scrubbing system 36 can determine if an error occurred 
in a field in the MICR line of the presented check due to a mistake in manual entry, 
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if there is a stop payment on file, or if the check was already presented for payment. 
The operator can then prevent the exception item from being sent to a client thereby 
ensuring that the client need only review "true" exception items that the financial 
institution using system 20 needs verification of validity. Scrubbing system 36 also 

5 refers to a database 32 to determine clients participating in system 20. Those clients 
who do not participate in system 20 will receive a notice of the exception items 
through conventional methods (e.g. facsimile, mail, etc.) as is shown at 35. The 
scrubbing process 36 then outputs a client image and exception file 38 which 
includes exception items and corresponding images for clients who participate in 

10 system 20. 

Client image and exception file 38 is fed through an electronic commerce 
gateway 40 and a firewall 42 to an integrated messaging exchange (hereinafter 
"IME") server 44. Electronic commerce gateway 40 prepares exception image file 38 
for delivery through IME server 44 by converting the file to XML (Extensive 

15 Markup Language) format. IME server 44 can be, for example, a TUMBLEWEED 
COMMUNICATIONS IME server made by TUMBLEWEED 
COMMUNICATIONS, INC. IME server 44 generates a Web file 50 (described 
more completely below with reference to Fig. 3) and a corresponding Uniform 
Resources Locator (hereinafter "URL") to address Web file 50. This URL is 

20 designed so as to be unique for each client of check exception item notification 

system 20 so that only a particular client can access the Web file 50 including check 
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exception items relating to that particular client. The URL is unique to both the 
individual e-mail address and the file so that two individuals do not access the same 
web page even if the exception information sent to these two individuals is identical 
(for example, two individuals within the same company which receive exception 
5 notification for the same account, receive a distinct URL). Moreover, the URL is 
changed each time a file a generated. 

12 As is known in the art, the URL can be entered into any standard Web 

C5 Browser and used to navigate through the Internet and make a connection with Web 

C3 

& file 50 through IME server 44. Examples of typical Web Browsers include 

*2 10 NETSCAPE NAVIGATOR, NETSCAPE COMMUNICATOR and MICROSOFT 

p INTERNET EXPLORER. The Web file 50 is stored on IME server 44. IME server 

U 

44 thus may be any computer device capable of providing Web page HTML and/or 

m 

Q JAVA data to a requesting device. 

IME server 44 further generates an e-mail file 46 that is sent to each 
15 exception client using a two-way communication channel that is secured using 

software such as that produced by TUMBLEWEED CORPORATION. E-mail file 
46 can contain a hyperlink to the unique URL created for the particular exception 
client. Referring to Fig. 2, there is shown an example of an e-mail file 46 that is sent 
to an exception client. As is shown in the figure, e-mail file 46 includes a message 
20 47 notifying the client of the exception item and a hyperlink 48 including the URL 
defined for Web file 50 to allow the exception client to quickly access Web file 50. 
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In the event that a client does not have any exception items for the day, the client 
will receive an e-mail stating "you have no exception items today" in the subject line. 
Such an e-mail will not include hyperlink 48. 

Referring again to Fig. 1, IME server 44 sends e-mail file 46 through a 
5 network 52 to an exception client 112. Network 52 can be, for example, the Internet, 
a value added network ("VAN"), or a corporate Intranet. Exception clients 1 12 of 
system 20 can access e-mail 46 using any known e-mail accessing device. For 
example, clients 1 12 can access e-mail 46 through a computer terminal 54, a 
computer terminal 55 coupled to another network 57 that is in turn coupled to 
10 network 52, a stand alone Web access terminal 56, a palmtop computer 58, a 
personal digital assistant 60, a personal Internet appliance ("PIA", not shown), a 
cellular telephone (not shown), a mailstation (not shown), a mass marketed Internet 
device like WEBTV (not shown), or any other type of Internet appliance. Other 
devices which can receive e-mail only could also be used (e.g. a telephone with text 
15 messaging capabilities or a pager) to access e-mail file 46. 

Once the exception client 1 12 receives e-mail 46 and is notified of the 
exception item (or items), the exception client has the option of quickly accessing 
information regarding the exception item. Exception client 112 can access Web file 
50 including such information stored on IME server 44 through any known method 
20 for accessing a file over a network. For example, exception client 112 can use the 
same one of the e-mail access devices mentioned above. Any one of these devices 
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could be used to connect over network 52 to thereby access Web file 50 stored on 
IME server 44. When attempting to access Web file 50, exception client 1 12 is first 
prompted to enter a unique password assigned to the exception client by a financial 
institution using check exception item notification system 20. Upon successful 
5 authentication, exception client 1 12 is presented with the contents of Web file 50. If 
the client fails to correctly authenticate itself with system 20, an error message is 
displayed and the client will not be able to view exception information. 

For example, the exception client 112 can use computer terminal 54 to 
receive e-mail 46 referencing the exception item and including hyperlink 48. The 
10 exception client 1 12 can quickly actuate link 48 to navigate through network 52 to 
IME server 44 and access Web file 50. The exception client can view the exception 
items (as detailed below) and provide authorization to pay or decline payment for 
each exception item. 

Fig. 3 shows a typical Web file 50 created in accordance with the invention. 

15 As stated above, Web file 50 includes a list of client exception items for a particular 
exception client. This list can include any type of check exception item indicia. 
These indicia can be, for example, those shown in Fig. 3. An account section 62 
indicates the account number of the exception client. A check number section 64 
indicates the check number of the exception item. An amount section 66 indicates 

20 the amount of the exception item listed on the payor's check. An image file section 
68 provides links to image files containing images of the exception items. A 

{00498224 .1} 



- 13- 



decision section 70 lists authorization or decision options for the exception client 
relating to the exception item. Image file links 72 allow the exception client to view 
an image of the exception item. A pay all button 74 allows the exception client to 
authorize payment of all of the displayed exception items simultaneously. A return 
all button 76, allows the exception client to decline payment of all of the displayed 
exception items simultaneously. A submit button 78 allows the exception client to 
submit the choices made in the decision section 70 to IME server 44. 

In use, exception client 112 reviews the contents of the exception items listed 
in Web file 50. Once the exception client opens Web file 50, a SMTP (Simple Mail 
Transfer Protocol) notice is sent from IME server 44 to electronic commerce 
gateway 40 informing electronic commerce gateway 40 that the exception client has 
accessed Web file 50. For each exception item, the exception client 1 12 has a choice 
under decision section 70 to authorize payment of the check ("pay") or decline 
payment of the check ("return"). The exception client 1 12 selects either "pay" or 
"return" for each one of the exception items listed. Once a decision has been made 
for all exception items, the exception client then clicks submit button 78 to send all 
decisions on the displayed page to electronic gateway 40. Each page is generally 
submitted individually. Clicking on submit button 78 will generate a prompt (not 
shown) inquiring as to whether the exception client is sure of her decision. When the 
exception client indicates that he is sure of his decision, processing continues. 
Actuation of submit button 78 will create a file of only those items to which the 
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exception client has responded. If the exception client does not provide a decision to 
all of the exception items (i.e. a "partial submission") all other exception items that 
have not been replied to will remain in Web file 50 and will appear again if the URL 
is later accessed. Conversely, those exception items for which the exception client 
does provide a decision, are removed from Web file 50. 

If the exception client desires, the exception client can choose to pay all of 
the exception items displayed on the current page of Web file 50, by clicking on the 
pay all button 74. Alternatively, the exception client can decline payment of all of 
the displayed exception items by clicking on the return all button 76. 

If any return decision is selected by the exception client with respect to an 
exception item (i.e. return for an individual exception item or use of the return all 
button 76), a drop down list 79 containing predefined reasons for the rejection is 
displayed from which the exception client 112 may choose. Return list 79 could 
include, for example, "refer to maker", "duplicate item", "check stopped", "stale 
date", and "suspect item" choices. A suspect item is a check that does not correspond 
to standard parameters to which checks of the exception client usually conform. If 
no reason is selected, an error page notice is generated by IME server 44 informing 
the client that a return reason should be selected prior to submission of the decision. 

If exception client 112 would like to view the check corresponding to a 
particular exception item, the exception client can click on one of the images file 
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links 72. Clicking on one of these links will bring the exception client to an image 
file 80, stored on server 44, corresponding to a particular exception item. Referring 
to Fig. 4, image file 80 includes an image 82 of the check front and an image 84 of 
the check back of the submitted payor check corresponding to the particular 
exception item. The exception client 112 can review the check images 82, 84 and 
decide whether to authorize payment of the exception item. A click on a pay button 
86 allows the exception client to authorize payment of the check whose image is 
displayed and a click on a return button 88 allows the exception client to refuse 
payment of the check whose image is displayed. Once the exception client 112 has 
made the decision, web file 50 is updated with the selected decision for the image 
file 80. 

All decisions made and submitted by the exception client (hereinafter 
generally referred to as "decision files") are received and processed by IME server 
44 and then sent to electronic gateway 40. IME server 44 can periodically (e.g., 
every hour from 8:00AM to 1 :30PM and then every five minutes between 1 :30PM 
and 2:00PM) send created decision files to electronic gateway 40. 

Each decision file has the exception client's account number and the date. If 
the exception client submitted a partial submission, IME server 44 holds the decision 
file until the submission is completed or until a designated time (e.g. 2:00 PM) 
during the business day. After that designated time, all decision files, regardless of 
whether they are partial submissions or not, are sent to electronic gateway 40. At a 
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desired time during the day (e.g. 3:30PM), the unique URL assigned to the exception 
client for Web file 50 can be set to be invalidated or expire so that the link is no 
longer available. Alternatively, the URL can be set to remain valid for a plurality of 
days. IME server 44 can be programmed to send an e-mail to electronic gateway 40 
indicating clients who have not accessed Web file 50 by a certain time during the day 
(e.g. 1 :30 PM). System mainframe 26 will periodically pick up decision files from 
electronic gateway 40, process the return files and pay or decline the payee bank 
accordingly. 

The exception client 1 12 is instructed by an institution employing check 
exception item notification system 20 to approve or disapprove each exception item 
on a current business day no later than an established decision deadline. If the 
exception client fails to provide electronic commerce gateway 40 with a decision 
prior to that deadline, a default decision of either "pay" or "return", depending on the 
client's service agreement, will be entered. 

Although a plurality of processors (e.g., mainframe 26, processor 30, gateway 
40, etc.) are shown, clearly it is within the scope of the invention to have most or all 
processing performed in a single processor. 

Thus, by providing an exception client with a prompt notification of 
exception items via e-mail, and allowing the exception client to view information 
and images relating to the exception items in a Web file through a uniquely defined 
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URL, a faster and more efficient exception check item notification system is possible 
than that available in the prior art. 

While preferred embodiments of the invention have been disclosed, various 
modes of carrying out the principles disclosed herein are contemplated as being 
within the scope of the following claims. Therefore, it is understood that the scope 
of the invention is not to be limited except as otherwise set forth in the claims. 
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